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ABSTRACT 


A real-time control system consists of a synergistic pair, that Is, a controlled 
jW’ocR.TO and a controlier nompixtp.r. Wo have defined new performance measures 
for real-time controller computers on thp oasis of the nature of tills synergistic pair. 


In this paper we present a case study of a typical critical controlled process in 
the context of new performance measures that express the performance of both 
controlled processes and real-time controllers (taken as a unit) on the basis of a sin- 
gle variable; controller response time. Controller response time is a function of 
current system state, system failure rate, electrical and/or magnetic interference, 
etc., and is therefore a random variable. Control overhead is expressed as a mono- 
tonically non-decreasing function of the response time and the system suffers 
catastrophic failure, or dynamic /adure, If the response time for a control task 
exceeds the corresponding system hard dea.dline, if any. A rigorous probabilistic 
approach is used to estimate the performance measures. 


Tlie controlled process chosen for study is an aircraft in the final stages of des- 
cent, just prior to landing. Control constraints are particularly severe during this 
period, and great care must be taken in the design of controllers that handle this pro- 
cess. First, the performance measures for the controller are presented. Secondly, 
control algorithms for solving the landing problem are discussed and finally the impact 
of our performance measures on the problem is analyzed, showing that the perfor- 
mance measures and the associated estimation method have great potential use for 
designing and/or evaluating real-time controllers and controlled processes. Also, one 
application for the design of controller computers, presented In detail, is checkpoint- 
ing for enhanced reliability. 


Index TerKi- Controlled prooess(es), controller computers, hard deadlines, response 
time, performance measu, es allowed state space, aircraft landing, checkpointii^. 
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1. INTRODUCTION 


Any real-time system oan be regarded us a eompoalte of controVed subsystems 
(henceforth celled aontraLlp.d proap.ssas) and contrcller subsystem(s). Tradition- 
ally, the perfornipnco of real-time control computers has been analyzed separately 
■ om that of the corresponding controlled processes. For example, the response delay 
caused by tho controller Is neither studied rigorouHy nor reflected carefully Into the 
design of control algorithms for the controlled processes. Tho design of the con- 
troller is frequently based on ad hoc requirements imposed by control designers. 
While this yields acceptable results In the control of non-critlcal processes, such an 
approaci) needs to bo improved in the design of controllers for critical processes e.g. 
aircraft. What is called for is a procedure for specifying and evaluating controller 
performance, enabling systematic application and providing objective results that 
lend themvselves to formal validation. The use of computers as real-time controllers is 
becoming increasingly attractive due to continuing advances in the development of 
Inexpensive, powerful microprocessors and memories. Hovi/ever, performance meas- 
ures presently used to characterize real-time computer systems are adapted ver- 
sions of those employed for more conventional computers. There is a considerable 
mismatch between the requirements of real-time applications and what is provided by 
these measures. 

To solve this problem, several contortions of the conventional measures have 
been proposed. Generally, these Involve representing real-time computer performance 
as a vector peR^, made up of such traditional indices as (conventional) reliability, 
throughput, survivability, availability, etc. However, it is impossible to compare two 
performance vectors (and therefore the corresponding computer systems) witiiout an 
associated metric. One straightforward aporoach is to use a linear metricO.e. inner 
product) to map the vector into a scalar that is then claimed to represent the perfoi- 
mance of the system. For example, the mapping can be carried out by assigning 
weights to the various components of the performance vector and adding them to 
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produce the scalar. That is, If the weight vector is w’^ - (wi, . . ,Wp), then the 

mapping Is / with / (p)=w'' p . 

This process of ascribing weights is largely subjective and Is therefore inaccu- 
rate to begin with. Even If the weight ascription were completely objective, serious 
practical difficulties would remain. For e,xample, since the components of the perfor- 
mance vector are mutually dependent (sometimes In a very complex manner), the 
weights (that are supposed to define the sensitivity of the scalar to the respective 
vector components) must be modified by (often very complex) correction factors to 
account for this coupling.^ Furthermore, relating the resulting scalar to "real-world" 
performance parameters (such as operating cost, etc.) is difficult. 

The performance measures we introduced in [1] are designed to get around 
these difficulties by expressing the performance objectively in terms of the 
response time of the computer-controller. From the point of view of the controlled 
process, the computer controlling it is a black box V:/hose behavior is exemplified by 
its response time and reliability. It is well known that controller delay has a detrimen- 
tal effect on process behavior, our measures take the form of a quantification of this. 
The performance measures are considered in Section 2 in some detail prior to the 
presentation of an idealized case-study of their application. 

The case-study is that of a real-time computer in charge of an aircraft in its 
final phase of flight, just prior to touchdown. There are stringent control constraints 
that must be met. These consist of limits on the speed of touchdown (both horizontal 
and vertical), the angle of attack, a, and the pitch angle, tJ. For a definition of these 
angles, see Figure 1. These constraints are variously intended to safeguard against 
running out of runway, undercarriage collapse, stalling, and landing either on the air- 
craft nose or tail. Insofar as this is a control problem with severe constraints, the 

^ T/?/s Is because the weights are supposed to represent the total derivatives of the mapped scalar to 
their respective components. However, since the components of p are not orthogonal, this Is not true for 
the unmodified weights', they represent the partial derivatives which are not equal In this case to the 
respective total derivatives. 
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problem is typical of many other critical applications, such as the control of nuclear 
roaorors, tiie generation and distribution o^" electrical power, life-support systems, 
etc. Since our objective hena is to illustrate the use of our performance measures and 
not to solve a control problem, the aircraft system is somewhat Idealized in this 
paper. 

Figure 2 shows the block diagram of a typical control system. The inputs to the 
controller are from sensors that provide data about the controlled process, and from 
the environment. This )S typically fed to the computer-controller at regular inter\/als. 
Data rates are usually low: generally fewer than 20 words a second for each sensor. 

Central to the operation of the system is the trigger generator. In most systems, 
this is physically part of the controller itself, but we separate them here for purposes 
of clarity. It is the function of the trigger generator to initiate execution of a con- 
troller Job (defined later). Triggers can be classed into three categories. 

(1) Timp.-generated iriggar: These are generated at regular intervals, and lead to 
the corresponding controller Job being Initiated at regular intervals. In control 
theoretic terms, these are open-loop triggers. 

(2) StatB-gsnGrated trigger: These are closed-loop triggers, generated whenever 
the system Is in a particular set of states. For practicality, it might be neces- 
sary to space these triggers by more than a specified minimum duration. If time 
is to be regarded as an implicit state variable, the time-generated trigger is a 
special case of the state-generated trigger. One can also have combinations oP 
the two. 

(3) Operator-generated trigger: The operator can generally over-ride the 
automatic systems, generating and cancelling triggers at will. 

The output of the controller 1; '"ed to the actuators and/or the display panel(s). 
Since the actuators are mechanical devices and the displays are meant as a human 
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Interface, the data rates here are usually very low. Indeed, as we have pointed out 
elsewhere [13], a computer control system exhibits a fundamental dichotomy, with 
the I/O being carried out at rather low rates and the computations having to be car- 
ried out at very high rates owing to real-time constraints on control. 

The controller In our case-study is a real-time computer. It executes pre- 
defined control jobs. There is a certain number of control jobs in any control system 
that are executed repeatedly. 

A control system executes "missions." These are periods of operation bet-veen 
successive periods of maintenance. In the case of aircraft, a mission Is usually a sin- 
gle flight. The operating interval can sometimes be divided down Into consecutive 
sections that can be distinguished from each other. These sections are called 
phases. For example, Meyer et, al [6] define tiie following four distinct phases in the 
mission lifetime of a civilian aircraft: 

(a) Takeoff/cruise until VHF Omnirange (VOR)/Distance Measuring Equipment (DME) 
out of range. 

(b) Cruise until VOR/DME in range again. 

(c) Cruise until landing is to be initiated. 

(d) Landing. 

The phase to be considered here is landing, it takes about 20 seconds. The 
controller job that we shall treat is the control of the aircraft elevator deflection dur- 
ing landing.^ 

The specific system employed Is assumed to be organized as shown in Figure 3. 
Sensors report on the four key parameters: altitude, descent rate, pitch angle, and 

^ The output cf the controller Ic assumed to be fed Into a peripheral processor that Is dedicated to 
controlling the actuator — In this case the elevator. 
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pitch angle rate every 60 milli-soconcJs.^ Wo have a tlrne-gonerated tririger, with a 
time period of 60 mflll-ueconds. every 60 Millhsecoiids, the controller computos the 
optimal Getting for the elevator, which is the only actuator used in the landing 
phase.® The execution time for the computation is nominally 20 milli-seconds, 
although this can vary in practice due to failures, Since the aircraft is a dynamic 
system, the effects of controller delay are considerable — as wo shall see in this 
paper. 

Since the process being controlled Is critical (i.e. in which some failures can lead 
to catastrophic consequences), variations of controller delay and other abnormal 
behavior by the controller must oe explicitly considered. For simplicity, we do not 
allow job pipelining in the controller; In other words a controller job must be completed 
or abandoned before its successor can be initiated. The following controller abnor- 
malities can occuri 

(I) The controller orders an incorrect output to the actuator. 

(II) The controller takes substantially more than 20 milli-seconds (the nominal exe- 
cution time) but less than the inter-trigger interval of 60 milli-seconds to com- 
plete executing. 

(ill) The controller takes more than 60 milli-seconds to complete executing. In such 
a case, the abnormal job is abandoned and the new one initiated. We say that 
a control trigger is "missed" when this happens. 

An analysis of controller performance during the landing phase must take each of the 
above abnormalities into account. 

^ The sensors and actuators are assumed to have their own dedicated processors for I/O purposes. 
When IV9 speak of "controller delay," ivc* also Include the delay in these processors. Also, the period of 60 
milliseconds Is arbitrary, and the choice of this period does not alter the method developed here. 

^ There are other actuators used aboard the aircraft for purposes of stability, horizontal spaed control, 
etc, \fVe do not however consider them here, concentrating exclusUely on the control of the elevator. 
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This paper Is organized as follows. In Section 2 we present the porforRmnce 
measures that will be used, and Section 3 contains u description of the oontrollod 
system. In Section 4, we derive the measures associated with the controlled process 
(the aircraft), and In Section 6 wo consider one ox.ample of their application for the 
design of real-time controllers. The paper concludes with Section S. 

2 . PERFORMANCE MEASURES 

2,1, Review of the Performance Measures 

For completeness, we review briefly In this section the performance measures to 
be used, which were introduced by us in [1]. 

The measures are all based on a single attribute: computer controller response 
time distribution. A real-time computer controller In general exhibits stochastic 
behavior.® Real-time computer controllers repeatedly execute predefined control jobs 

I 

which are. Initiated either by environmentai stimuli or internally. 

Central to our performance measures are the concepts of dynamic failure and 
allowed or admissible state-space. Every critical process must operate within a 
state-space circumscribed by given constraints. This is the allowed state-space. 
Leaving this state-space constitutes dynamic failure,'^ In the example we treat 
here, the states are the altitude, the vertical speed, the pitch angle, and the pitch 
angle rate. Each of these has a constraint. For example, the aircraft must not touch 
down with too great a downwar"’ velocity or the undercarriage will collapse. 

The performance of the controlled process naturally depends on the speed of 
the controller. If the controller takes longer than a certain duration to formulate the 
control, dynamic failure becomes possible. This duration is the hard deadline, 

® This Is partially because failures are assumed to occur randomly over the operating Interval, Tho 
failure law for the components of the computer Is assumed to he known. Furthermore, execution of control 
tasks Is stochastic due to the blocking at shared resources, conditional tranches In task code, etc. 

^ Dynamic failure Is so termed since It Is a failure that can occur as a result of the controller not 
responding fast enough to the environment. It expresses the fact that slowness of the controller can be a 
cause of catastrophic failure. 
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Wo define a cost function Ca(0 a«sociatod with controiler response time ^ for 
controller job a, Tho coot function takes the following form*, 


CM) = 


ffaU) if 

“ if 


( 1 ) 


0 of/ierooisa 

where Pa(0 a suitable continuous non-decreasing function of f and Tact is the hard 
deadline associated with the job a. Clearly, since the environment influences the 
quality of system performance the cost function is Implicitly a function of the system 
state. Also, if r^a >s a finite quantity in some region of the state-space, the Job is 
aritical in that region. The determination of the hard deadline is treated in detail in 
Sections 2.2 and 2.3. . 


For controller response times less than tho hard deadline, tho cost function In 
(1) above is continuous, monotonically non-decreasing, and therefore always 
bounded for finite response time. For consistency, It Is assumed that the costs 
accrue as the execution proceeds. 

The functions (called the finite cost functions) can be obtained using the 
performance indices of the controlled process. These performance indices are wed- 
known to control theory and express the consumed energy, fuel, time, or some other 
physical parameter associated with the trajectory of the system as it travels from its 
initial to its final state. See, for example, [2,3], for details. The cost of running the 
controlled process over, say, an interval of time [t^Jj-], is usually expressed by: 

0 = f E[foix.it)Mt),i)’\y{r),tti^r^t]dt 
h 

Vi/here represents conditional expectation, /<, is the instantaneous index of 

performance at time t, and x(^)eK’^, u(t)ciR^ and y(i)sR’” represent the state, 
input, and measurement vectors respectively. A good representation for QaiO 
given by; 


8 



9a{i) = 


(3) 


for 0-^ ^ < Taa 
0 othp.'ruiiv^a 

where = expected contribution of Uea to 0 If response time of that particular 
execution of job a-r}, and Uc« - control Input subvector associated with job a. Note 
that the Input vector u for Job a consists of the control input subvector, u^ai as well 
as the environment (random) Input subvector, Uc«. 

A version Is an instance of the execution of a task. Versions are numbered In 
sequence of initiation: succesvsive versions of task I beitig denoted by 
The response time associated with a version Is denoted by RESP{ij). 

Let g;(0 represent the number of versions executed for task I over the interval 
and r the number of distinct tasks. Then define 

S{t) a £rt(0 
<=1 

?<(0 f Qiit) if 

whars r, = J^h,{[iESPiis)) and h,{t) = | 

For an illustration, see Figure 4. Clearly, is the cost function Q "hard-limited" at 
9i{^di)' Ti is essentially the finite operating cost associated with task I. 


Rotaark: It ndfiht legitimately be argued that to associate a contribution to finite cost after the 
hard deadline has been missed is inconsistent with the notion of hard deadlines hciiig "absolute" in 
the sense that missing a hard deadline, by definition, has catastrophic consequences (c.g., an air- 
plane crash). By this argument, /tj (j! ) = 0 for all t >ta. However, such an u-ssignment would, while 
pacifying the purists, lead to ^mpjca3a^t anonmlics, not the least of which is that a very poor sys- 
tem which almost always misses deadlines would exhibit a amhllcr finite operating cost than a 
counterpart that almost always fulfiUH them. 

Also, assume that the computer system is modelled as a Markov process. This is 
clearly possible. The numi er of states® depends on the extent to which the system 
Is capable of graceful degradation. Let B be the set of states where the probability 
of failure is unity. These states represent the states when the extent of 


^The word "state" used here has a different connotation from the "state" discussed in the preceding 
sections. The latter has a control -theoretic meaning. On the other hand, the state of controller computers 
usually means the number of functioning praoessors, buses, memories. Jobs, etc. However, both forms of 
usage conform to the essential concept of "state," as a codification of relevant system condition. For this 
reason, the same word has been used for the two different purposes, following the usual practloe. Its In- 
terpretation should be made from the context. 
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hardware/software ooilapse Is so grsat that there Is a ?,ero probability of successful 
execution of any task hi finite time. Let L(t) denote the probability distribution of the 
operating interval duration between two successive i orvice stages. 

Our performance measures are then:^ 

Px’obability of Dynamic Failure, /irfyni This is the probability that over the operating 
Interval, at least one hard deadline is missed for whatever reason. This probability 
Incorporates within It the probability of stciLio failura, which is the probability that 
so massive a hardv./are failure has occurred that the system utilization is greater than 
unity. Static failure probability has erroneously been treated In most of the literature 
as expressing the total probability of failure. This is most decidedly not the case in 
real-time systems. 

Mean Modified Cost, M c J'E\S{t) \ system never enters state set B\dL{t) 

0 

It can be shown that, for ptiysical systems, this Integral always exist since the life- 
time is always finite with probability 1 , 

The performance measures can be used to rank rival computer systems and to 
help design improvements to existing systems m the context of the control applica- 
tion. Typically, the probability of dynamic failure is used as a pass/fait test for can- 
didate controllers. This test can be very severe: for example, 10"° is the specifica- 
tion for failure probability adopted by NASA for computer controllers of the next 
decade handling a 10-hour civilian flight. The mean cost is then employed to rank 
controllers that have passed the dynamic failure criterion. For fuller details, see [1], 

Note that all parameters associated with these performance measures can 
either be definitively estimated or objectively measured. Also, the measures specifi- 
cally incorporate the controlled process into a determination of the controller's 

® There are other performartce measures developed In [1 ], but not considered here. Far our purposes, 
the measures listed here are sufficient. 


70 



capabilitfoa. This Is, ns far as we know, a novel approach which ensures that the per- 
formance measures are not generally, hut instnocl specjifically, Indicative of the con- 
troller performance in a given application. For this reason, these measures are Intrin- 
sically more rePablo than others In use. 

2.2, Hard Deadlines 

Roughly speaking, hard deadlines are deadlines that must be m.et If catastrophic 
failure is to be avoided by a critical process. Ir. other words, it is the deadline that, If 
met by the controller in (correctly) formulating its response, erisures that the system 
remains In its allowed state-space. Tradition 'dv, it has been assumed by computer 
engineers that the hard deadlines for each critical controller job are somehow 
"given", Unfortunately, this presupposes a precise definition of the liard deadline 
and a means for obtaining It. Neither seems- to exist in the literature. 

At first glance, it might seem that the hard deadlines can be obtained relatively 
easily from an analysis based on the state equations of the controlled process. This 
Is the case when individual controller actions are decoupled from each other and the 
process Is simple. For an example in which this is the case, see [1]. However, when 
there Is a considerable coupling between individual controller jobs, i.e., when two or 
more controller jobs mutually affect each other, or when no closed-form solutions are 
available for the process state equations, obtaining a hard deadline for each can be 
difficult. For example, In the aircraft landing problem, the controller has over the 
twenty seconds or so that it takes to complete the landing, to compute the elevator 
deflection a number of times (in our example about 330 times). The constraints are 
on the final values (except for the angle of attack), i.e., as long as the aircraft 
touches down on the runway without over- or under-shoot, with an acceptable velo- 
city and at a proper pitch angle, dynamic failure has not occurred. The problem here Is 
that it is not just a single controller action that determines whether catastrophic 
failure will occur or not; it is the cumulative effect of, in this case, 330 or so distinct 
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controller actions. How then Is cno to allocoto deadlines to tho Individual actions? 

It Is clear that we need a more carefully dofinocl frumework to handle these 
problems In a foasible manner. For this it Is convenient to represent tho controlled 
process by a state-spaco moc.el. Lot the state of the system at time t bo donotud 
by x(0« State transitions are characterised by a mapping Tx'I’aX^U > X where T c. 
K represents the time reglont the state space, and Uf tho input spacej that 
Is, 

xUi) = 1 , /to. x(fo). u) (4) 

where uc U roprosents the controls (inputs) applied to the process In tho Intorval 
[jfo.fi). Let HeU be the admissible Input space (l.o. the range of Inputs that It Is pos- 
sible to apply), and X^eXthe allowed stato-space. Then, the hard deadline as.soci- 
ated with controller Job a triqgerod at Iq when tho system Is In state x(fo) Ls given 
by 

■Tda(x(/to)) ^ i’}/ I t*! 95(fo4-T, Zq. >«(^c). u) G X,i| 

Uwll 

Thus, for every point In the state space, we have for each critical controller job a 
corresponding hard deadline.''® 

It should be noted that the calculation in (5) (s performed over the entire admis- 
sible state and input space and is thus difficult to achieve. One inigiit wish to per- 
form the calculation over only a subset of the admissible Input or state space. To 
allow for this, the notion of conditional hard, doadlinns can be employed. Let us 
assume that the sets «c0 and oeX^ are specified, and also that x(Zo)Ga. 


Notice In this context that It Is not possible for the hard deadline as dufined above to be negative 
unless this is the first Instance during the current mission that the controller Jab Is being executed. This Is 
because If this were the case, failure would already have occurred on the previous execution of the con- 
troller Job by definition, Also, the deadline on the first Instance of execution of tho control function cannot 
be negative, since that would mean that the controller-process system hsd been Improperly designed. 
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Ths ocTulih'onaL harr^, dnadtina^^ of job a, c^oisotnd by rda j,.at dofinod as 

Tdaiti.oWo)) - infs'vp fr!v3(4+T. Iq. x(^o). «) r aj 

uf u 

For the purposes of the case-study In this paper, however, vje ehall rostrici our- 
selves to tho unconditioned hard doudlinas. 

As it stands, the oxprosslon for tho hard deadline (and for the conditional doad- 
llnos) Is not easy to obtain for the entiro state-space. In fact, It is almost impossible 
to obtain in closed form in all but tho simpler control systems. We shall later see how 
';o obtain a good approximate expression of Tda< 

Also, if tho environment is stochastic in cliaractor and not dotormlnistic, the hard 
deadline Is a random variable. Assuming that the environment is stochastically sta- 
tionary leads to tho o.xistenco of tho distribution function of tho hard doadlino. 

2.3, / dow, s State-Space and Its Decomposition 

As we said above, it is difficult to dotormiiie ti’.e hard deadline and the finite 
cost function as a function of the stats over the entire state space. To take our 
present example of an aircraft, the solution of the state equations is not obtainable 
in closed form when controller delay Is considered. To obtain the functional depen- 
dence of the hard deadlines or the finite cost function of each controller Job on the 
current state vector Is thereforo Impossible to do analytically, and prohibitively 
expensive to do numerically for a largo number of sample states. 

To get around this problem, we divide the allowed state-space down into S7ib- 
spacas. SubvSpacos are aggregates of states in which the system exhibits roughly 
the same behavior. In each subspace, each critical controller job has a unique hard 

^ ^ Unlike the unconditioned hard deadline, It Is possible for the conditional hard deadline to be nega- 
tive since no specific relationship Is required between the subsets w and a, 

^^Even If there do not exist clear boundaries for these subspaces, one can always force the admissi- 
ble state space to be divided Into subs paces so that & sufficient safety margin can be provided. This Is a 
designer's cholco for approximation. 
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Komarks: In xome riubrpnccs, n jolj described in .^cncrnl ac "oriiic/i! ’ ini^bt not be erit’cnl in the 
sense that even if Uie execution dchiy associated with it is infimly, caUstrophic ftulurc docs not 
occur. Tliut is, the associated hard deadline may be infinity for a purticular subspacc. Whut 4ioea; 
usually happen in these circumstances is that xhc system moves into a ncT» subspnee — Cr ut the 
least toward the subspacc boundary — in which the danp.crs of catastrophic failure are flrealer. In 
tliis subspaoc, the requirements on controller delay arc more strinreat, and there ml/jht well be a 
hard deadline, representing a critical task, 'i’luis a "critical" job need not be truly cribcjil in every 
subspnee, it only has to map into a critical fuvk - defined in the sequel — in at least one subspnee. 
Also, subspuces arc job-rclafad, i.c, the same allowed state space can divide into a different set of 
subspuccs for each control job. 

For convQnlenco, a controller "tasK" is defined as follows. 

Dofinition: A cantrollor task, often abbrev/iated to "task", Is defined as a controller 
job operating within a dOvSignatod subspace of the allowed state space. 


Let Bi for i=0,l,...,s be disjoint subspaces of with denote a 

1=1 

controller job. Then, we need the projectlonj( X 4 ) -> ((Tq, So), (7’i, Si), Ss)) 

where is the cofitroller task generated by executing J in Si. With each controller 
task, we may now define a hard deadline Without the coupling problem mentioned 
above. We denote it by critical task Tt (for convenience, however, the super- 

script J will be omitted in the sequel). We will see that a critical Job can possibly 
map into a non-critical task for one or more allowed siibspace; it only needs to map 
into a critical task tn at lea^t one such subspace to be considered critical. 


A, Allowed State-Space 

The admissible state-space is the set of states that the system must not leave 
if catastrophic failure is not to occur. Consider the two sets of states Xj and Xf 
defined as foilov/s. 

(i) Xj is the set of states that the system must reside in if catastrophic failure is 
not to occur immediately . For example, we may define in tlie aircraft landing 
problem, a situation in which the aircraft flies upside down as unacceptable to 
the passengers and as constituting failure. Notice that terminal constraints are 
not taken into consideration here unless the task in question is executed just 
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prior to mission termination. 


01) X:f is the set of accofnablo states given tho terminal constraints, i.e., it is tlie 
sot of states from which, givon tho constraints on tho control, it becomes possi- 
ble to satisfy the terminal constraints. 

Note that leaving Xj moans that no matter how good our subsequent control, failure 
has occurred.^® On tho other hand, changing the control available can affect the set 
X|. The admissible state space is then defined as X,^ ? Xj. 

Obtaining state-space X| can be difficult in practice. The curse of dimensional- 
ity ensures that even systems with four or five state variables make unacceptable 
demands on computation resource; for the accurate determination of the allowed 
state-space. Howevisr, while it can be very difficult to obtain tho entire allowed 
state-space, it is somewhat easier to obtain a reasonably large subset, X^cX,i. By 
defining this subset as the actual allowed state-space, (I.e., by artificially restricting 
the range of allowed states), we make a conservative estimate for the allowed 
state-space. Note that by making a conservative approximation, we err on the side 
of safety. Also, the information we need about X^j may be determined to as much pre- 
cision as we are willing to invest in computing resources. 

In what follows, to avoid needless pedantry, we shall refer to the artificially res- 
tricted allowed state-space, X?. simply as the "allowed state-space." 

B. On Obtaining the Subspaces 

While the methods used to isolate the subspaces for each particular control 
application will probably be different, the basic approach is much the same in all 
cases. Let N(x) represent a neighborhood of xcXi» and ^di(x) denote respec- 

tively the cost function and the hard deadline associated with Ti where ^ represents 

strictly speaking, of course, there can be no subsequent control since by leaving Xj the system has 
failed catastrophically before the next control could be Implemented , 
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the controller response time, and rf:XxX » R is a metric function. Then the sub~ 
spaces So. Si '4,. of X^i can be obtained by the followinQ steps. 

51. Choose a set of <! points, Pi gX^, 

52. Construct a neigliborhood around each of those points, N(p..) for p^, such that 
(I) All N(pi)'s are disjoint and X'^cljN(pi). 

i 

(H) Udi(x) “ ^di(Pi)l ^ Ki for all xGN(pi) and for -=’ome Ki>0. 

Oil) d{C^{(:), KzfiiO for all xGN(pi) and for some 

monotonicaliy non-decreasing positive function /i(0 iiTg > 0. 

53. jf Q + i"‘ ) /fs/ (f) for i=l,2 some /f g > 0, and monotonicaliy 

non-decreasing positive function f'(^) then merge N(pi) and N(pi+.i) forming 
subspaces S = (Sq, Si, Sj). 

54. It S satisfies all the requirements of the application jobs then successful 
decomposition else choose a different set of points and go to S2. 

The job of dividing X; i.»to S= (Sq, Si, ..., Ss) is sometimes made easy by the 
existence of natural cleavages in the state-space, when the latter is viewed as an 
Influence on system behavior. In most cases, however, such conveniences do not 
exist, and artificial means must be found. The problem then becomes one of finding 
discrete subdivisions of a continuum. 

The method we employ is to quantize the state continuum in much the same way 
as analog signals are quantized into digital ones. Intervals of hard deadlines and 
expected operating cost (i.e. the mean of the cost function conditioned on the con- 
troller delay time, and using the distribution of the latter) are defii ' Then, points 
are allocated to subspaces corresponding to these intervals. To tak concrete 
example, consider a state-space XcR” that is to be subdivided on the basis of the 
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hard deadlines. The first step is to define a quantization for the hard deadlines. Let 
this be A, Then, define subspace Sv as containing all states in wliioh the hard dead- 
line lies in the interval [(i-l)A, xA). Alternatively, one might define a sequence of 
numbers Aj, A^, ...'••^uch that the subspaces were defined by intervals with the A's as 
their end-points, Thfe would correspond to quantizing with variable step sizes. The 
subspace in which the job under consideration maps into a non-oritical task is a spe- 
cial case and Is denoted by Sq. 

Subspaces can also be defined based cn a quantization of the expected 
operating cost or on both the operating cost and the hard deadlines. We provide an 
example of subdivision by hard deadlines in Section 4. 

The size of each subspace will depend on the process state equations, the 
environment, and how much computing effort it is Judged to be worth spending on 
obtaining the subspaces. Naturally, all other things being equal, the smaller a sub- 
space the greater the accuracy of the inherent approximation.^^ 

In tlie rest of the paper, to illustrate the derivation of the performance meas- 
ures, we carry out their evaluation when the controlled process is an aircraft in the 
phase of landing. Also, an optima! checkpointing is considered for the design of a reli- 
able controller. 

3. The CONTROLLED PROCESS 

The controlled nrocess is an aircraft, in the phase of lending. The mode! and the 
optimal control solution used are due to Ellert and Merriam [4]. 

The aircraft dynamics are characterized by the equations: 

= dii 2 :i (0 + 6 ig 2 :g(f) + bia2;3(0 + Gii7ni(f,^) (6a) 

(6b) 

1 4 

^ The error that ensues as a result of quantization of the state space can be estimated In the same way 
that quantization error Is estimated In signal processing theory. 
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«3(0 = &32»a( 0+^33® 3(0 

(6c) 

Xi{t) = ^ 3(0 

(6d) 


where xg is the pitch angle, xi the pitch angle rate, -.j the altitude rate, and x^, the 
altitude, mi denotes the elevator deflection, which Is the sole control employed. The 
constants bij and c n are given in Table 1. Recall that ^ denotes controller response 
time. 


The phase of landing takes about 20 seconds. Initially, the aircraft is at an alti- 
tude of 100 feet, travelling at a horizontal speed of 256 feet/sec. This latter velo- 
city Is assumed to be held constant over the entire landing interval. The rate of 
ascent at the beginning of this phase is -20 feet/sec. The pitch angle is ideally to 
be held constant at 2°. Also, the motion of the elevator is restricted by mechanical 
stops. It is constrained to be between -35° and 1 5°. For linear operation, the eleva- 
tor may not operate against the elevator stops for nonzero periods of time during this 
phase. Saturation effects are not considered. Also not considered are wind gusts and 
other random environmental effects. 


The constraints are as follows; The pitch angle must lie between 0° and 10° to 
avoid landing on the nose-wheel or on the tail, and the angle of attack (see Figure 1) 
must be held to less than 18° to avoid stalling. The vertical speed v./ith which the air- 
craft touches down must be less than around 2 feet/sec so that the undercarriage 
can withstand the force of landing. 


The desired altitude trajectory Is given by 


hAn = 


100e~‘/s 

2Q~t 15tit£;.20 


while the desired rate of ascent is 


hAt) - 


-1 15<i<20 


The desired pitch angle is 2° and the desired pitch angle rate is 0° per sec. 


( 7 ) 


( 8 ) 
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The performance Index (for the aircraft) chosen by Ellort and Merriam and suit- 
ably adapted hero to take account of the nonzero controller response time ^ Is fjiven 
by 

If 

'SiD = f .()dt 
^0 

Where t. represents time, and [io. ^/ ] is the Interval under consideration, and where 

where the d-subscripts denote the desired (i.e. ideal) trajectory. To ensure that the 
touch-down conditions are met, the weights 95 must be impulse weighted. Thus we 
define: 


9h{t) = 954(0 + c34.<^c5(20-O 

( 10 a) 

~ + ?^’3.<yf5(20-O 

( 10 b) 

- 9’3.«^(0<5(20-0 

( 10 c) 

^^(0 = 5»i(0 

(lOd) 


where the functions <p must be given suitable values, and 5 denotes the Dirac-delta 
function. The values of the cp are given based on a study of the trajectory that 
results. The chosen values are listed in Table 2. 

The control law for the elevator deflection is given by: 

-k -^)-k,,{t -0] 

Where tiie aircraft parameters are given by: Ks - —0.95 sec~', 7^ = 2.5 sec, 
Wj = 1 radian sec"^ and the constants k_ are the feedback parameters derived (as 
shown in [4]) by solving the Riccatian differential equations that result upon minimiz- 
ing the process performance index. For these differential equations we refer the 
reader to [4]. 
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4, DERIVATION OF PERFORIVIANCE MEASURES 


VVe consider here only one controller task: that of computing the elevator 
deflection so as to follow the desired landing trajectory. The Inputs for the controller 
here are the sensed values of the four states. 

We seek the following Information. As the controller delay increases, how much 
extra overhead Is added to the performance Index? Also, it Is intuitively obvious that 
too great a delay will lead to a violation of the terminal (landing) conditions, thus 
resulting In a plane crash. This corresponds to dynamic failure, and we are naturally 
Interested in determining the range of controller delays that permit a safe landing. 

Consider first a formal treatment of the problem. The control problem is of the 
linear feedback form. The state equations can be expressed as: 

x(0 = Ax(f) + Bu(0 

where the symbols have their traditional meanings. Define the feedback matrix by 
S(0- Then, clearly, 

u(0 = 

For a small controller delay (i.e., a small f), the above can be expanded in a Taylor 
series and the terms of second order and higher discarded for a linear approximation. 
By carrying out the obvious mathematical steps, we arrive at the equation: 

as representing the behavior of the system (assuming the given initial conditions). 
For further details, see Figure 6. 

Given a closed-form expression for the that appear in we could 

then proceed to study the characteristics of the system as a function of the matrix 
E. However, in the absence of such closed formulations for the kij, we must take 
recourse to the less elegant medium of numerical solution. 

The procedures we follow for obtaining the numerical solution are as follows. 
First, the feedback values are computed by solving the feedback differential 
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equations that define the These are not affected by the macnitudo of the con- 
troller delay. Then, the state equations are solved as simultaneous differential equa- 
tions, These are used to check that the terminal constraints have been satisfied, and 
in the event that they are the performance functional Is evaluated. This procedure 
must be repeated for each new subspace. Since the environment Is deterministic in 
this case (no wind gusts or other random disturbances are permitted in the mode!(6)), 
the hard deadline associated with each process subspace is a constant and not a 
random variable. 

The trajectory followed by the aircraft when the delay is less than about 60 
milli-seconds follows the optimal trajectory closely although the elevator deflections 
required would bo intuitively assumed to increase as the delay increases. Also, the 
susceptibility of the process to failure in the presence of incorrect or no input Is 
expected to rise with the introduction of random environmental effects. 

The control that Is required for various values of controller delay Is shown in Fig- 
ure 6. Due to the absence of any random effects, elevator deflections for all the 
delays considered tend to the same value as the end of the landing phase (20 
seconds) is approached, although much larger controls are needed initially. In the 
presence of random effects, the divergence between controls needed in the low and 
the high delay values of controller delay is even more marked. We present an exam- 
ple of this in Figure 7, The random effect considered here is the elevator being stuck 
at -35“ for 60 milli-seconds 8 seconds into the landing phase due to a faulty con- 
troller order. The controlled process is assumed in Figure 8 to be in the subspace In 
which the landing job maps into a non-critica! process (defined in the sequel as So). 
The diagrams speak for themselves. We shall show later that this demand on control 
is fully represented by the nature of the derived cost function. Also, above a cer- 
tain threshold value for controller delay, we would expect the system to become 
unstable. This is indeed the case in the present problem, although this point occurs 
beyond a delay of 60 milli-seconds for all points in the allowed state space (obtained 
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In thn next sGctlon), which cannot by dofinltion occur hero. 


4,1. Allowed State Space 

In tills subsection, we derive the allowfjd state space of the aircraft system. To 
do so, note that in Hllert and Merriam's model, Xj does not exist. The reason is that 
the state equations do not take Into account the angle of attack. In the idealized 
model we are considering, it is Implicitly assumed that the constraint on the angle of 
attack Is always honored, so that the only constraints to be considered are the ter- 
minal constraints. 

The terminal constraints have been given earlier but are repeated here for con- 
venience. The touchdown speed must be less than 2 feet/sec in the vertical direc- 
tion, and the pitch angle at touchdown must lie between 0° and 10°. To avoid 
overshooting the runway, touchdown must occur at between 4864 and 5120 feet in 
the horizontal direction from the moment the landing phase begins. The horizontal 
velocity is assumed to be kept constant throughout the landing phase at 256 
feet/sec."'® Thus, touchdown should occur between 19 and 20 seconds after the 
descent phase begins.^® The only control Is the elevator deflection which must be 
kept between —35° and 15°. 

The set of allowed states is generally found by solving the differential equa- 
tions for the system backwards from the point of landing. However, this can be com- 
putationally expensive, so we follow a cheaper alternative. The initial conditions of 
the process as it enters the landing stage are known. Also known is that the con- 
troller is triggered every 60 milli-seconds. It is assumed that the computations take a 
minimum of 20 milli-seconds to complete. Using these data, it becomes possible to 
determine that portion of the allowed state-space that the controlled process is t 

^ ® We do not consider here how that Is to be done; In practice this will constitute a second controller 
Job, We do not treat this here. 

This make.s time an "Implicit" state variable. 
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likely to enter to a good approximation. In Figure 8, ws plot the range of allowed 
state values that wa ''’btain. As indeed it should bo, the allowed state-s; aco is a 
function of time. 

4.2. Designation of Subspaces 

We subdivide the allowed stato-spaco found above using the method described 
In Section 2. The criterion used is the hard deadline, since the finite cost function 
(derived in the next subsection) is found not to vary greatly within the whole of the 
admissible state-space. The value of A chosen is 60 milli-seoonds, In other words, 
we wish to consider only the case where a trigger is "missed." 

The allowed state-space in Figure 8 is subdivided into two subspaces, ‘^nd 
Si. These correspond to the deadline intervals [60, 120) and [120, ^). Sq is the 
non-critical region corresponding to the [120, “) interval. Here, even if the controiler 
exhibits any of the abnormalities considered in the Introduction, the airplane will not 
crash. In other words. If the controllers orders an incorrect output, exhibits an abnor- 
mal execution delay or simply provides no output at all before the following trigger, 
the process will still survive at the end of the current Inter-trigger interval if, at the 
beginning of that internal, it was in S^. 

On the other hand, if the process is in S] at the beginning of a inter-trigger 
Interval, it may safely endure a delay in controller response. However, if the controller 
behaves abnormally in either providing no output at all for the current trigger cycle or 
in ordering an incorrect output, there is a positive probability of a air crash. 

Notice that we explicitly consider only missing a single trigger, not the case 
when two or more triggers might be missed in sequence. This is because dynamic 
failure is treated liere as a function of the state at the moment of triggering, if two 
successive triggers are missed, for example, we have to consider two distinct 
states, namely the states the process is in at the moment of those respective 
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trlggGr.s. To speak of doadlino Intervals beyond 120 milli-seconds Is therefore mean- 
ingless in this case since the triggers occur once every 00 mllll-seconds. Thl^ Is why 
the second deadline Interval oonsidnred Is [ 1120 , '»), not [ 130 , 160 ). 

The hard deadline may conservatively bo assumed to bo 60 niilll-sooonds In Sj. 
By definition It is Infinity In 

4.3, Finite Cost Functions 

As indicated In the preceding section, the finite cost does not vary greatly 
within the entire allowed state-space. It Is therefore sufficient to find a single cost 
function for Sq or Sj. 

The determination of the cost function is carried out as a direct application of 
its definition. That Is, the process differential equations are solved with varying 
values of The value of ^ cannot be greater than tfie Inter-trigger interval of 00 
milli-seconds since, by assumption, no job pipelining is allowed and the controller ter- 
minates any execution in progress upon receiving a trigger. The finite cost function 
Is defined as^^ 

( 12 ) 

This function is found by computation to be approximately the same over the entire 
allowed state-space as defined in Figure 8. 

In Figure 9, the finite cost function Is plotted. TUd costs are In arbitrary units. 
Bear in mind that these measures are the result of an Idealized model. We have, for 
example, ignored the effects of wind gusts and other random effects of the environ- 
ment, When these are taken into account, the demands on controller speed get even 
greater, i.e. the costs increase. 

^ ^ Recall that ) represents the contribution to the performance functional by a version that takes ^ 
units of time to compute. Since there Is only one controller Job under consideration, the subscript on has 
been suppressed. 
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ThQ reader should compere the nature of the cost function with the plots show- 
ing elevator deflection in Pigure 6, and notice the correlation between the marginal 
Increase In cost with Increased execution delay and the marginal increase In control 
needed, also as a function of the execution delay. 


6. APPLICATION EXAMPLE FOR CONTROLLER DEvSIGN: CHECKPOINTING 

With stringent requirements on the reliability of any computer controlling a 
highly critical system. It becomes necessary to obtain mechanisms to Identify and 
correct controller errors. Two characteristics must be exhibited by any such mechan- 
Ismj a high probability that errors once existing are caught In time, and a fast moans 
for recovering from the error. In this section, we deal with the latve;. 

One common recovery method Is the use of the racavtiry block or recovpry 
region which establishes checkpoints and saves the current job states during normal 
execution. When an error is detected, the system rolls back to the state saved at 
the previous checkpoint and the affected task-version Is resumed. Clearly, check- 
points can enhance the reliability of execution and reduce the recovery overhead. 
They can also, however, ler;d to Increased controller overhead since the Insertion of 
checkpoints Increases controller delay. It is therefore Important to carefully check 
during design if any overall benefits accrue from the installation of checkpoints, and 
not to include them anyway through an ad-hoc design procedure. Checkpoints should 
be regarded as useful supplementary devices to enhance reliability in certain cases, 
not as a panacea for reliability problems. It is the purpose of this section to demon- 
strate the use of the performance measures described above in a study of the 
effectiveness of checkpointing. Specifically, wo shall in this section consider (a) 
whether checkpointing is indicated In our aircraft landing problem, and (b) if so, what 
the optimal number of checkpoints is. 
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SovarnI methods for analysing the rollback recovery system have been proposed 
[8 - 1Ji], They in general compiito the opiinium Inter-ohockpoiiit Interval for minliiiMm 
total execution time. In [12], a complete expression for the characteristic function 
of total execution time Is given which takes Into account liiiperfections In the check- 
points, the occurrence of error during recovory, and multi-stop rollback. However, 
when mean time between failure (MTB.'^) Is many orders of magnitude larger than both 
the nominal task execution time (() and the duration of the phase (i^), the model for 
solving the probability distribution of the task execution time and the probability of 
dynamic failure with checkpoints can be simplified. 

Let hours. This Is a roasonablo assumption given contemporary pro- 

cessors ([7], pag^ 101). Then in the landing phase, the ratio of ^ to MTBF is of the 
order of 10"*°. It Is therefore an acceptable approximation to assume in computing 
the execution time that no further errors ocf'ur during error=rect very. 

Let the occurrence of error be a Pek-aon process with rate \-^\/ MTBF. Let 
h> ^ov denote the time needed to set up rollback, restart, and checkpoint. Also, 
we assume that the saved state may be contaminated with probability which 
means the system can be recovered using rollback with probability and has 

to restart with probability p^. Thus, we have the total execution tl -je ol' one version, 
fr > 

~ ^ TZfjv + tj-gg (13) 


where n is the number of checkpoints Inserted and f^ec is the time overhead used for 
recovery, tj.gc is a random variable which depends on the probability of failure, p(,i 
and ps . 


0 


f: 


rcc 




si art 


if no error occurs 

if error occurs and the version is recovered 
if error occurs and the version restarts 


by 


rollback: 


14 ) 


where and t^.(ari are the computation undone b.:cause of rollback and restart. 
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respectively. Let fmi, b© tho Interval between checkpoints and equal to ^/(n + l). 
The density function of and tfiart ^•’o glvcm by /nuiU) “ ” n for 

K[0,/ltnw] °nd fstartiO ^ (1 ~ a ^0 for iU [0,(], respectivoly. 

Lot the density of total execution time solved from above equation be 
Then the mean execution cost and tho probability of dynamic failure aro given by 

COSf-''tff({t)h,j{t)dt US) 

i~\ 0 

Pw - i.o-fl('..o-//((0<«-r/i) U6) 

#'■ <1. 

Where Is the number of versions executed for 'i\ during a phase, hij tho cost func- 
tion for executing tho jf-th version of 7\, the deadline associated with the j-th 
version of 7\, and Is the probability of static failure for the j-th version of 7\ dur- 
ing ^ which can be regarded as tho probability of resource exhaustion, unsuccossful 
recovery, successive failures during recovery, etc. 

Using the cost function and hard deadlines given in tho above section, and 
assuming that ph Is the probability of having an error during recovery, the Improve- 
ment in the probability of dynamic failure, Pdyn> ^ipon Insertion of checkpoints are 
shown in Table 3,^® The probability of dynamic fallu, does indeed decrease as more 
checkpoints are inserted. Unfortunately, vhe mean execution cost Increases in as 
this is done. Through the cost functions it is possible to express the precise extent 
of this cost increase, and decisions about tradeoffs can be made. 

When the nominal execution time Is 20 milli-seconds as assumed in the rest of 
this paper, all that checkpoints do Is tu Incroase the overhead, i.e. the mean finite 
cost. No discernible drop exists in the probability of dynamic failure when check- 
points are added. The marginal gain in reliability for any payment In finite operating 
cost is therefore about zero. This was only to be expected since the nominal execu- 
tion time is one-third that of the hard deadline and the probability of dynamic failur«i 
since the landing Job Is noncriticel In Sq, the Issue of checkpointing does not arise there. All re- 
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without checkpoints was vanishingly small. 

However, as the nominal execution time Increasos (the hard deacifine being 
assumed to be its Sj value of 60 milli-seconds), tiie benefits of checkpointing 
emorge. This Is made clear tlirough the fourth column In Table 3 where we present the 
marginal tradeoff ratio between the benefits gained In the form of improved reliability 
and the loss In the form of increased controller overhead. As Is evident from this, for 
20 milli-seconds nominal execution time, the optimal number of checkpoints Is zero. 
For 30 miiil-seconds, there is something to bo gained in reliability by putting in one 
checkpoint, for 40 milii-secondc, there is a gain to be ^.ad on adding up to two check- 
points although the marginal gain falls off sharply after the first. For a nominal execu- 
tion time of SO milli-seconds, the benefits continue rather steadily until four check- 
points have been added. The fifth checkpoint provides some not! oable improvement 
in reliability, although the marginal gain is distinctly smaller than for the first four. The 
recommendation? for design are now rather clear; use no checkpoints If the nominal 
execution time is 20 milli-seconds, and use Table 3 to decide on the optimal number 
of checkpoints for the other cases. 

6. DISCUSSION 

In this paper, we have presented a case-study of the determination of perfor- 
mance measures introduced in [1], and considered an important application in con- 
troller design. 

Central to our paper i.s the idea that it is possible to objectively quantify the 
performance of a controller. Owing to this objectivity, there are many possible exten- 
sions to this work. One extension, presently under study, is the issue of distributed 
control, and the cost of transmitting global status information to all the local controll- 
ers, For guaranteed reliability, the local controllers require a complete knowledge of 

marks In this section are theretcre concerned with the characteristics of the process In Sj. 
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the global state of the system. This, however, has a cost In terms of the exrra 
response times exhibited by the overall ccntrollor, If the local coiitrolle-’s have less 
than complete Information, their actions cannot be optimal and might even be 
Incorrect. However, the response time of the controller could be significantly reduced, 
with errors occurring rarely enough to make that an improvement. Readers will recog- 
nize this formulation as an example of the application of Markov decision theory with 
costly Information with the cost functions for the controller jobs now providing the 
cost of status information. 

Other applications Include the quasi-optimal allocation and reallocation of control 
jobs to different processors In a multiprocessor controller, the dynamic control of 
queues in controllers, and the objective ranking of rival computer systems as con- 
trollers of any specific process. 
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Figure 1. Definition of aircraft angles (from [4]) 




Figure 2. A typical real-time control system 
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Hgure 4. Illustration of Cost Functions. 
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Figure 5. The Approximate State Flquations 
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Figure 6. Elevator Deflection.. 
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Figure 7. Elevator Deflection, with. Abnormality, 
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Figure 0(c). Allowed State Space: Pitch Angle. 
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I'lgare B(d). Allowed Slate Space: Pitch Angle Rate. 


COST 



Feedback Term 

Value 

fan 

-0.600 

fa u> 

-0.760 

. fain 

0.003 

fa ri!J 

102.4 

fann . . . . 

o 

Sjll 

-2.374 


Table 1. P^eedback Values 


Weighting Factor 

Value 

^i(^) 

99.0 


20,0 

(ps{t) (0</l<15) 
<p^(t) (15^i«20) 

0.0 

0.0001 


1.000 

9^4 

0.00005 


0.001 


Table 2. 'Weighting Factors 




















n 


MEAN COS'r 


Pdyn 


TradeoffxlO'^ 




1 


0 

0.1 3846 

0.3086E-15 

- 

1 

0.13909 

0.3066E-15 

0.0 

2 

0.13971 

0.3086PM 5 

0.0 

3 

0.13033 

0.3086E-15 

0.0 

4 

0.13095 

0.3086E-15 

0.0 

5 

0.13157 

0,30B6E-15 

0.0 


(a). Nominal execution time SO msec. 


n 

MEAN COST 

Pdyn 

Tradevff'xlO'^ 

0 

0.30156 

0.37037E-07 

- 

1 

0,36431 

0,37037E=08 

131.5 

3 

0.36709 

0.37037E-08 

0.0 

3 

0.36991 

0.37037E-08 

0.0 

4 

0,37373 

0.37037E-08 

0.0 

5 

0,37567 

0.37037E-08 

0.0 


(b). Nominal execution time 30 msec. 


n 

MEAN COST 

Pdyn 

Tradeoffx 10'^ 

0 

0,55353 

0.30555E-06 

- 

1 

0.55473 

0.43055E-07 

3177.0 

3 

0,55586 

0.30555E-07 

109.8 

3 

0,55694 

0.30555E-07 

0.0 

4- 

0,55795 

0.30555E-07 

0.0 

5 

0.55891 

0.30555E-07 

0.0 


(c). Nominal execution time 40 msec. 


Table 3. Checkpoints 


















































































n 

MKAN COST 

Pdyn 

p- - - -J 

Tradeoffx.lO'’ 

0 

0.09694 

0.46666E-06 

- 

1 

0.90848 

0.35666E-06 

95.6 

8 

0.98025 

0.26166E-06 

80.6 

3 

0.93231 

0.16666E-06 

78.7 

4 

0.94466 

0.71666E-07 

76.9 

5 

0.95730 

0.46666E-07 

19.8 


(d). Nominal execution time 50 msec. 


MTBF~\Q^ hours , ms&c, lij, =3.0 msec, =2.0 ttisbc. 


Tradeoff ratio forn checkpoints (n>l) 

_ COST with n checkpoints - COST with n-1 checkpoints 
Pdyn with n-1 checkpoints -pdyn with n checkpoints 


Table 3. (Cont.) Checkpoints 



























